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INTRODUCTION 

During the past years, the progress in digital control systems 
and, in particular, the increased functionalities of controller 
and sensor/actuator devices, as well as the progress in com- 
munication techniques, have allowed the development of 
high-performance industrial communication systems, called 
fieldbuses [1], 

Fieldbuses are networks for which hardware, software, 
and protocols have been specifically designed in order to 
interconnect field devices, such as sensors/actuators, with 
controller devices and to integrate the plant control systems 
in the overall plant information hierarchy [2], 

Several fieldbuses from many different vendors are cur- 
rently available off-the-shelf. However, a standardization 
process carried out in the last years has tried to stop the 
increasing presence of proprietary products. The standard- 
ization process had, as a goal, to facilitate the development 
of universal control strategies, increase safety and security, 
decrease costs for installation, maintenance, monitoring and 
diagnostics, and, finally, allow interoperability and software 
portability between different products. 

INDUSTRIAL COMMUNICATION SYSTEMS 

The typical structure of an industrial communication system 
is shown in Figure 37.1. As can be seen, networks are widely 
used to connect the different industrial devices. In particular, 
three different communication levels can be distinguished: 
device of field, cell, and plant levels. 

The communication at the field level takes place 
between the controller devices and the sensor/actuator 
devices. This kind of communication consists, typically, of 
high-speed cyclic transmissions of data (cycle times may 
be as low as some hundreds of microseconds) from/to the 
plant, sometimes interrupted by transmissions of alarms. 
Moreover, usually, the field level communication is charac- 
terized by the exchange of small amounts of data (tens of 
bytes or less). 

At the cell level, the operations of the different controllers 
are monitored and coordinated. For this reason, communica- 
tion at this level is characterized by the transmission of larger 
amounts of data, necessary for configuration, calibration. 


collection of statistics, etc. Since all these functions are not 
time critical, transmission times at the cell level can be lon- 
ger (hundreds of milliseconds or more). On the other side, 
the amounts of data exchanged are increased, on the order of 
some kB, or even more. 

Finally, at the plant level the production strategies are 
managed, that is, at this level, different entities, such as 
Enterprise Resource Planning (ERP), resource allocation, 
management, etc., must be put into communication in order 
to be able to exchange data among each other and, at the 
same time, with the lower layers. Communication at this level 
is characterized by the exchange of considerable amounts of 
data, while time is no longer an issue. 

Fieldbuses are used in industrial communication systems, 
both at the field and cell levels. 

At the field level, fieldbuses allow replacing point-to- 
point connections between controllers and sensors/actuators, 
for example, to reduce cabling (decreasing the complexity of 
the communication system, the installation and maintenance 
costs, and the risk of failures), to easily add/remove nodes 
to/from the network, and to test and calibrate the system 
remotely. 

In the past, the data exchange between field control- 
lers and cell controllers was realized in different ways. For 
example, a storage device could be used at the field level to 
memorize large quantities of data and then, in a later step, 
manually moved from one controller to another. Sometimes 
serial communication systems based on proprietary pro- 
tocols were used as well. Thus, at the cell level, fieldbuses 
allow easily and automatically realizing the connection with 
the lower levels. 


FIELDBUSES BASIC FUNCTIONS 

In order to be employed at both the field and cell levels of an 
industrial communication system, fieldbuses have to provide 
a set of basic functions necessary for the communication at 
these levels. Specifically, as described in Ref. [1], they have 
to be able to perform 

• Cyclic data exchange 

• Asynchronous traffic management 

• Messaging 
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FIG. 37.1 

The automation system of plants using communication networks. 

Clearly, the implementation of this set of functions may vary 
from fieldbus to fieldbus. 

Cyclic Data Exchange 

Thanks to the cyclic data exchange, a controller is able to 
periodically transmit/receive data to/from the sensors/ 
actuators connected to the plant and communicate with them 
through the fieldbus. 

Typically, at each cycle, the controller reads the input 
signals coming from the field from each sensor and sends 
the output control signals to each actuator. The duration of 
the time interval necessary to execute all these operations is 
called cycle time and it is a key parameter of the communica- 
tion system performance. Indeed, the cycle time represents 
the sampling time of the overall controlled system and it is 
important to keep it low and constant. The small fluctuations 
of the cycle time, which can be caused by several factors such 
as delays due to the sharing of transmission medium, elabo- 
ration of data, etc., are called jitter. Jitter badly influences the 
overall controlled system and, consequently, it is important to 
keep it as small as possible. 

Basically, the cyclic data exchange function can be imple- 
mented in two different ways as follows: 


• Message based 

• Producer-Consumer 

In the message-based implementation, a device on the net- 
work has to be defined by the user as the master station 
(usually the controller), while all the other stations are slave 
stations (usually the sensors/actuators). 

Before the cyclic data exchange begins, a configuration 
phase takes place, during which some basic information is 
exchanged between master and slaves (e.g., a number of bytes 
to be transmitted/received at each cycle, type and amount of 
diagnostic data, and the way in which safety procedures are 
implemented). 

After the initialization, both master and slaves make use 
of the data transfer facilities provided by their data link layer 
protocols to actually execute the data exchange. An exam- 
ple of the message-based implementation of the cyclic data 
exchange function is provided in Figure 37.2. 

As can be seen, a cycle starts with the query of the 
first slave (#1 in the figure) and ends with the last slave 
(#n in the figure). Then, either a new cycle may be started 
immediately or some other actions can be undertaken (e.g., 
asynchronous operations). In some cases, an idle period 
might be waited. Furthermore, as described in Ref. [1], 
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FIG. 37.2 

Message-based implementation of the cyclic data exchange 
function. 

sometimes Time Division Multiple Access (TDMA) tech- 
niques are adopted to implement the cyclic data exchange 
function. In this way, a cycle is split in some constant time 
intervals reserved for specific actions (cyclic transmission, 
acyclic transmission, and maintenance). Such a solution 
allows obtaining constant cycle times but, on the other 
hand, it may be scarcely efficient (e.g., during the cycles 


in which no acyclic traffic is present, the time reserved for 
it has to be waited anyway, with a consequent wasting of 
bandwidth). 

The Producer-Consumer technique is based on the defi- 
nition of a set of variables that can be transmitted on the field- 
bus. For each variable, there is only one producer (the device 
that actually sends that data on the network) and there can be 
one or more consumers (the devices interested in receiving 
that data). During an initial configuration phase, an identi- 
fier is assigned to each variable so that the devices connected 
to the network can recognize whether they are interested in 
receiving it or not. 

In some fieldbus networks, there is usually one station 
(named scheduler) that manages the operations on the sys- 
tem, granting the right to transmit to the producer devices. 

Figure 37.3 shows an example of operation of a Producer- 
Consumer fieldbus. Variable A has only one consumer, while 
variable B is used by two consumer stations. 

As can be seen in this figure, the production request of 
variable A is issued by the scheduler and received by all the 
stations. As a direct consequence of this request, the pro- 
ducer of variable A broadcasts its value on the network. Then, 
variable A is received by its consumer. Figure 37.3 shows also 
an example of production of variable B. The whole sequence 
is the same as in the previous case, the only difference being 
that variable B has two consumers. 
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FIG. 37.3 

Producer-Consumer implementation of the cyclic data exchange function. 
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As a final remark, it is worth observing that the Producer- 
Consumer technique does not require the stations present on 
the network to have physical addresses assigned to them. 

Asynchronous Traffic 

The asynchronous traffic management allows the fieldbuses 
to handle sporadic events such as alarms. Usually, when a 
sensor detects a critical event, it uses this functionality to 
communicate it to the controller that, in turn, has to under- 
take the appropriate actions. Sometimes, the implementa- 
tion of this function allows indication of the priority of the 
detected event as well. 

Usually, the asynchronous traffic management has to 
coexist with the same protocols used for the data exchange 
functionality. As a consequence, the realization of the asyn- 
chronous traffic handling is strongly dependent on the tech- 
nique used for the cyclic messaging. 

If the cyclic data exchange is message-based, then the 
slaves typically are not granted with autonomous access to 
the network. Hence, a slave having an alarm to send has to 
wait to be polled by the master in order to notify it. This 
may take place, for example, by setting a suitable held in the 
response frame issued by the slave. In a subsequent step, the 
master will directly request the alarm to the slave with a spe- 
cific query. For these types of asynchronous traffic handling, 
the maximum latency between the detection of the event 
generation by the slave and the subsequent reception of the 
notification by the controller is given by the cycle time of the 
network. 

If the cyclic data exchange follows the Producer- 
Consumer strategy, the station that needs to notify an event 
has to wait for the controller request to produce a variable. 
Then, it may set a specific field in the variable production 
frame, similar to the message-based technique. Subsequently, 
that station will be either granted the access to the network 
for a short time (necessary to transmit the alarm) or directly 
requested to send the alarm in response to a specific frame. 
The maximum latency in this case is mainly determined by 
the periodicity of the variable produced by the station that 
needs to send the alarm. 

Messaging 

The messaging function is essential for the communication 
at the cell level, that is, for the management of the opera- 
tion of the controllers employed at the field level. In this 
case, the amount of data to be transferred is larger than in 
the previous cases. Indeed, data can be configuration files, 
regions of memory (domains), and executable programs 
(program invocations). As a consequence, the messaging 
function has to provide services like reading/writing of com- 
plex variables, domain uploading/downloading, and remote 
starting/stopping of program invocations. 

Most of the protocols implementing messaging function 
use a subset of the Manufacturing Message Specification 


(MMS) [3], which has been the first standardized protocol for 
the application layer of industrial communication systems. 

STANDARDIZATION 

During the first years of commercialization, the heldbus mar- 
ket has suffered from the absence of leading standards. As 
the main consequences, integration between products from 
different vendors was difficult and the devices’ manufactur- 
ers were obliged to develop products with many different 
interfaces in order to make them suitable for the different 
fieldbuses. 

Likely, the problem has been caused by a certain delay in 
undertaking the appropriate standardization actions by the 
competent bodies. Meanwhile, proprietary products prolifer- 
ated on the market, making the standardization efforts even 
more complicated. 

Subsequently, the standards organizations have under- 
taken some actions in order to solve, at least partially, the 
problem of interoperability, issuing some standards and 
grouping several existing products, even if most fieldbuses 
are still incompatible between themselves. 

In the following section, a short history of the heldbus 
standardization process is provided. 

The process was started in the late 1980s by different 
organizations such as the International Electrotechnical 
Commission (IEC), the International Standard Organization 
(ISO), the European Committee for Electrotechnical 
Standardization (CENELEC), the Instrumentation Society 
of America (ISA), the American National Standard Institute 
(ANSI), and the Electronic Industries Alliance (EIA). The 
process may be considered still in progress, since new prod- 
ucts are currently being added to the standards whereas some 
others are going to be removed. 

European Standards 

The most important European Standard was EN50170, issued 
in 1996 by CENELEC. It describes some general purpose 
fieldbuses that can be used for both the held and cell levels. 

Specifically, the EN50170 standard grouped together 
three heldbuses previously recognized as National Standards 
by three European countries: P-Net [4] (Denmark), Prohbus 
[5] (Germany), and WorldFIP [6] (France). Subsequently, 
Foundation Fieldbus [7] and Control Net [8] were added. 

Another important European Standard is EN50254, 
issued in 1998, that grouped some heldbuses purposely 
developed for use at the held level. In particular, the stan- 
dard included two heldbuses extracted from the EN50170 
(Prohbus DP and WorlFIP Profile 1) and Interbus [9]. 

Both EN50170 and EN50254 European Standards are no 
longer active, since they have been replaced by the IEC61158 
International Standard that will be discussed below. 

Other two European standards have been issued, namely, 
EN50325 [10] and EN50295 [11], The hrst one refers to 
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three application layer protocols, namely, CANopen [12], 
DeviceNet [13], and Smart Distributed System [14], based on 
the well-known Controller Area Network (CAN) [15]. 

EN50295, on the other side, is concerned with the 
interfacing of controlgears and switchgears in the low 
voltage electrical distribution environment and comprises 
a German fieldbus, namely, the Actuator Sensor interface 
(AS-i) [16]. 

International Standards 

The leading international Standard in the fieldbus area is, 
currently, IEC61158, issued in 2000. It originated from a 
common agreement (Memorandum of Understanding) signed 
by the major fieldbus manufacturer organizations aimed at 
producing an international fieldbus standard. For this rea- 
son the specifications of seven already existing heldbuses 
(ControlNet, Prohbus, P-Net, Fieldbus Foundation HSE, 
SwiftNet, WorldFIP, and Interbus) were included in the stan- 
dard and added to the so called IEC Technical Specification 
(a fieldbus proposal originated from the ISA SP50 project 
that never led to any practical implementation). 

The resulting document is the IEC61 158 standard. During 
the years, some heldbuses have been added to IEC61158, 
whereas some others have been removed. Moreover, the first 
version of IEC 61158 was based on the definition of network 
types, whereas the last version (issued in 2007) has intro- 
duced the concepts of communication profile and commu- 
nication profile family (CPF). Fieldbus profiles are defined 
by IEC61784-1 [17]. This standard contains several CPFs, 
which, according to its definition, “specify one or more com- 
munication profiles. Such profiles identify, in a strict sense, 
protocol subsets of the IEC61158 series via protocol specific 
communication profiles.’’ It is worth mentioning that a com- 
panion standard, IEC61784-2 [18], has been issued and it is 
concerned with the profiles defined for Real-Time Ethernet 
networks. 

Table 37.1 provides a description of IEC61158, which 
shows the evolution of this standard over the years. 


Another important standard concerning heldbuses is 
IEC62026, issued in 2000. It comprises heldbuses already 
dehned in the EN50295 and EN50325 standards, restrict- 
ing their use to the low-voltage electrical distribution 
environment. 

A further well-known standard is the IS011898, CAN 
[15], which was originally issued for cabling of automotive 
systems within vehicles. Its performance hgures along with 
the easy availability of low-cost components have made the 
adoption of CAN both possible and convenient in other envi- 
ronments where heldbuses are traditionally used. IS011898 
specihes only the hrst two layers of a typical communica- 
tion stack, namely, the physical and the data link layers. This 
has caused the appearance on the market of several products 
implementing the application layer protocols and functions 
on top of CAN. Some of these, as mentioned above, have been 
included into European as well as International standards. 

Finally, two additional networks worth being cited are, 
namely, Lonworks and Modbus. 

Lonworks is a communication system, designed mainly 
for domestic applications, which may be conhgured to 
work as a heldbus. Originally dehned by the ANSI/EIA 
709 Standard [19], now, it has become an ISO/IEC14908 
International Standard [20]. 

Modbus [21] is a very popular, widespread, master-slave 
protocol that can be placed on the top of several different 
physical layers such as RS232, RS422, RS485, and, recently, 
Ethernet and TCP/IR In particular, Modbus TCP has been 
recently comprised in the IEC61784-2 standard, where it is 
referred as CPF #15. 


PERFORMANCE 

The performance required from a heldbus depends on the 
automation level at which it has to operate. 

At the cell level, the services of the messaging sys- 
tem have to be executed employing times on the order of 
some hundreds of milliseconds. Considering that a typical 


TABLE 37.1 

IEC 61158 Fieldbus Standard 

IEC61 158-2000 

IEC6 1158-2007 

Type 1 

Foundation fieldbus H 1 . H2 

CP 1/1: Foundation fieldbus HI; CPI/3: Foundation fieldbus H2 

Type 2 

ControlNet 

CP 2/1: ControlNet; CP 2/3: DeviceNet 

Type 3 

Profibus 

CP 3/1: Profibus DP; CP 3/2: Profibus PA 

Type 4 

P-Net 

CP 4/1 P-Net RS-485; CP 4/2 P-Net RS-232 

Type 5 

Foundation fieldbus HSE 

— 

Type 6 

SwiftNet 

CP-F7: REMOVED 

Type 7 

WorldFIP 

CP 5/1; CP 5/2; CP 5/3: WorldFIP 

Type 8 

Interbus 

CP 6/1; CP 6/2; CP 6/3: Interbus 



CP 8/1; CP 8/2; CP 8/3: CC-Link 



CP 9/1: HART universal command 


Note: CP n/m, Communication Profile # m of the CPF # n. 
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communication service at this level can involve the transfer 
of some tens of kB, then, roughly, the data transfer rates have 
to be greater than 1 Mbit/s. Such a speed is provided by most 
of the available fieldbuses. 

The application layer protocol of a fieldbus, operating at the 
cell level, usually introduces a model by means of which each 
station is considered as a container of communication objects. 

These communication objects are the only entities that 
can be exchanged on the fieldbus and they represent, for 
example, variables, domains, program invocations, and 
events. The data exchange can take place either with the con- 
nectionless or connection-oriented type of transmission, and 
for this purpose the client-server model is typically used. 

There is no specific performance indicators defined for 
fieldbuses employed at the cell level. However, the aforemen- 
tioned communication services lead to a network behavior, 
which is similar to that of other types of networks such as 
LANs. Thus, in this context, it may be helpful to refer to 
some performance indicators as well as quality of service 
parameters that are typical of these latter type of networks. 
Likely, the most important index is the throughput , which is 
defined as the number of bits per second actually transmit- 
ted on a specific link [22]. However, since not all the bits 
transmitted carry useful information (clearly, there are some 
fields in a frame that contain information necessary for the 
correct operation of the communication protocol and that, 
consequently, do not carry any plant data). Thus, the above 
definition may be further refined referring specifically to the 
payload bits. 

Various several additional performance indicators may 
be considered, depending on the specific application, for 
example, when high reliability is required, then an important 
metric to evaluate is the frame loss ratio, defined as the ratio 
between the number of lost frames and the total number of 
transmitted frames. In the same context, the availability of a 
link, defined as the percentage of time over a defined period 
of operation in which that link is available for data transfer, 
represents another useful indicator. 

At the device level, the correct operation of a fieldbus has 
to ensure short cycle times with a very low jitter. However, 
as the amounts of data to be transmitted are low and the pro- 
tocols used are very efficient, the data transfer speeds can 
be less than those required at cell level. In general, it may be 
sufficient if these speeds are >500 kbit/s. 

As for the cell level, no specific performance indicators 
have been defined by the standardization bodies. However, 
considering the typical operation of a fieldbus at the device 
level that has been previously discussed, two indexes may 
be straightforwardly introduced [23], namely, the Minimum 
Cycle Time, MCT, and the jitter, J. 

The MCT is particularly suitable for networks that oper- 
ate on the basis of a cycle such as those that adopt a message- 
based implementation of the cyclic data exchange function 
(but it may be profitably used for the Producer-Consumer 
technique as well). Practically, in these networks, a cycle is 
continuously executed, during which all the activities of the 


nodes are scheduled. Hence, the cycle time is a parameter 
set by the user at the beginning of the network operation. 
Clearly, such a parameter cannot be chosen arbitrarily, since 
it has a lower bound determined by several factors such as 
the network configuration, the amounts of data transferred 
between the nodes, and the latencies of the components 
employed. On the other hand, the minimum time requested 
to execute a cycle is a crucial indicator of the overall behavior 
of the network. Indeed, it represents the minimum amount of 
time which has to elapse between two consecutive executions 
of one cyclic action (i.e., reading/writing of data from/to a 
network node). Thus, MCT can be defined as the minimum 
sampling time achieved by the network system. 

The presence of jitter may be caused by several factors, 
for example, unpredictable transmission delays and/or errors 
(as described, e.g., in Ref. [24] for Profibus), latencies in the 
network stations and/or components. Formally, the jitter may 
be defined as follows: 


J = 


\T r -TP\ 


(37.1) 


where 

T c is the nominal cycle time (i.e., the value set at the 
beginning of network operation) 

T” is the actually measured value 

Some additional performance indicators may be derived 
directly from the theory of communication networks, and 
they are directly concerned with the behavior of the data link 
layer protocols. 

The first very important parameter to be taken into 
account when operating at the device level is the efficiency of 
the protocols used to implement the fieldbus functions. 

There are three different definitions for the efficiency, 
related to the symbol coding, the data coding, and the 
medium access. These three efficiency definitions are not 
correlated among them, but should be separately evaluated 
when choosing a fieldbus to be used at device level. 

The symbol coding efficiency, r| sc is relevant to the 
transmission of a symbol on the network and it can be 
expressed as 


Bsc - 


Nusf 

Ntrn 


(37.2) 


where 

N usf is the number of useful bits of the symbol 
N trn is the number of bits transmitted (i.e., including all 
those necessary for the coding of the symbol) 

The evaluation of T| sc is particularly simple when using 
character-oriented protocols; for example, Profibus DP has 
r|s C = 8/11, as for each 8 bit symbol, it transmits 11 bits, add- 
ing start, stop, and parity bits. 
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However, for a bit oriented protocol it is more difficult to 
determine q vc , because, normally, control bits are added in 
a way that depends on the contents of the transmission. For 
example, the CAN data link layer protocol, in order to force a 
transition in the output signal, adds one “stuff” bit after every 
five consecutive transmitted bits of the same value. In this 
case T| sc is not a constant, but it can be reasonably estimated 
as not less than 4/5. 

The data coding efficiency, r\ DC , is concerned with the 
services of the data link layer. In this case, it is expressed 
as the ratio between the number of user data bits actually 
transmitted and the overall number of bits necessary for the 
execution of the service (considering also the delays intro- 
duced by the stations). Obviously, the data coding efficiency 
depends on the type of service and the number of user data 
bits. 

As an example of calculation, in Ref. [25], the behaviors 
of the data coding efficiency for two popular fieldbuses are 
reported. 

The medium access efficiency, t\ ma in general, allows for 
the evaluation of the overhead introduced by the medium 
access technique used by the fieldbus. It is expressed by the 
ratio, within a cycle, between the time actually employed for 
data transfer and the total cycle time. 

To give an example, the data link layer protocol of 
Profibus DP is based on a token passing access method. The 
medium access efficiency, r) MA for this fieldbus takes into 
account the time spent in circulating the token between the 
master stations. It can be expressed as 


Fma — 


T r - NT r , 


( 37 . 3 ) 


where 

T c is the cycle time 

Ttk is the time necessary to pass the token from one sta- 
tion to another 

N is the number of master stations connected to the 
fieldbus 



FIG. 37.4 

Physical layer redundancy. 


can be caused, for example, by a break in the network cable, 
or, if active components are used (e.g., hubs), by an inter- 
ruption of the power supply. In this case the only solution 
to guarantee the correct continuation of the fieldbus opera- 
tion is the use of a redundant physical medium, realizing a 
configuration similar to that shown in Figure 37.4. As can 
be seen, every station is connected to two physical mediums, 
of which only one (the primary) is active. When the primary 
fails, communication is switched to the redundant physical 
medium. The way in which this switching takes place is par- 
ticularly important for the features of the stations and for the 
overall performance of the fieldbus system. 

If the switching is manual, then when a fault occurs, the 
system has to be stopped, and the stations have to be com- 
muted onto the redundant physical medium and subsequently 
restarted. In this way, there is an interruption of the opera- 
tion, but the stations are not required to supply additional 
features, with the (possible) exception of the connection to 
two separate physical mediums. 

If the switching is required to be automatic, then each 
station has to be able to recognize a malfunctioning of the 
primary physical medium and switch over to the redundant 
physical medium. As can be imagined, this procedure is par- 
ticularly complicated and its implementation can be consid- 
erably expensive. On the other hand, manual switching, if 
necessary, is easily implemented. 

Station Failures 


In Ref. [26], a detailed description of the medium 
access efficiency for Profibus DP and the IEC Technical 
Specification is given. 

REDUNDANCY AND FAILURE CONSIDERATIONS 

There is, in general, the necessity of protecting the operation 
of a fieldbus against several sources of failure. The concepts 
illustrated in this section are applicable to fieldbuses used 
either at device or cell level. 

Physical Medium Failures 

At the physical layer, the most serious fault, which can occur, 
is the interruption of the connection between the stations; this 


Malfunctions occur when a station has a failure that compro- 
mises its participation to the fieldbus operation. It is obvious 
that the effects of the failure on the network depend on the 
role played by that station. 

If the role is critical (typical examples are “masters” or 
“schedulers” for fieldbuses used at device level), then there 
can be serious consequences. Generally, in these cases, the 
operation of the fieldbus is stopped and the other stations, 
which are no longer updated (slaves and producers/consum- 
ers), have to guarantee that the parts of the plant under their 
control are put in a safe state. 

It is important to observe that some fieldbus specifica- 
tions foresee the possibility of having redundancy for criti- 
cal stations. For instance, WorldFIP and the IEC technical 
specification may have more than one station with scheduler 
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capability connected; only one is working as scheduler at a 
time and one of the others can automatically replace it in case 
of fault. 

When a problem occurs on a noncritical station (e.g., a 
slave), then the fieldbus operation can continue. Normally, 
the defective station is marked as inactive and this situation 
has to be signaled to the fieldbus administrator who, in turn, 
will initiate suitable recovery actions. More importantly, 
however, the defective station has to maintain the plant under 
its control in a safe state. 

Transmission Errors 

Every communication system is subjected to transmission 
errors, which can corrupt the contents of the information 
they carry. If, as in the case of fieldbuses, digital transmis- 
sion techniques are used, the occurrence and the effects of 
such errors may be carefully bounded. 

In particular, as for most of the communication systems, 
every fieldbus is able to detect, and in some cases correct, 
any possible loss or corruption of information during trans- 
mission. These objectives are achieved using suitable control 
bits and/or check fields, which are added to the useful data 
to transmit. It is worth noting, however, that these techniques 
have the disadvantage of reducing the transmission effi- 
ciency, which, as previously discussed, in case of fieldbuses 
represents a crucial performance indicator. 

In practice, two types of checks may be executed: on the 
characters and on the frames. 

The checks on the characters are performed by fieldbuses 
that use character-oriented protocols to access the physical 
medium. It is the case, for example, of Profibus that uses 
a Universal Asynchronous Receiver Transmitter (UART) 
by means of which each octet is transmitted using 11 bits. 
On the receiver side, the control bits of each character are 
checked. If an error is detected, the frame to which the char- 
acter belongs is discarded and, if possible, requested to be 
retransmitted. 

A similar technique, known as block checksum, can also 
be applied to a block of characters to evaluate a global parity 
bit determined by the single parity bits of each character. 

Frame checks are typically executed by all fieldbuses. 
They are based on the calculation of one or more octets 
obtained as result of a polynomial function applied to the 
frame to be transmitted. These octets are appended to the 
frame and then sent on the network. The receiver applies 
the same function to the received data and, if the results are 
different, it deduces that a transmission error occurred. The 
octets obtained by the computation are referred to as Frame 
Check Sequence (FCS) or Cyclic Redundancy Check (CRC). 

An important additional technique, which is frequently 
used to detect and correct transmission errors, is the use of a 
high Hamming distance for fields of a frame whose meanings 
are critical. 

Considering a field of a frame for which only a defined 
set of values (codewords) are possible, the Hamming distance 


is the minimum number of bits in which the contents of two 
codewords must differ. 

If an error occurs during transmission and a codeword is 
corrupted, then a sufficiently high Hamming distance allows 
the receiver to detect errors and, possibly, correct them by 
assigning the value of the “closest” codeword to the received 
field. 
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